DevOps实践——打造自服务持续交付（上）｜洞见
本文首发于InfoQ:
http://www.infoq.com/cn/articles/devops--build-self-service-continuous-delivery-part01
DevOps转型的动机
我们的客户是一家海外本土最大的金融保险集团，他们在发展到一定规模以后，意识到自己就像一头笨重的大象，举步维艰，通过对整个交付流程的思考和分析，发现了以下一些严重影响交付速度的问题：
一些好的关于产品改善和创新的想法很难落地。涉及到一些遗留系统的配合：调整、部署、扩展等，使团队对发布没有信心。新的服务或者应用的构建，很难快速上线，被卡在了生产环境部署阶段。
各种不同种类的应用、服务的部署方式和流程不一致。运维部门作为一个支持部门，很难为大量团队提供快速反应。运维人员对于需要部署和运营环境之上的产品也不够了解。
微服务运营过程中，交付团队难以做到快速集成和部署。运维团队对微服务的部署运维方式不理解，依旧老瓶装新药，很难适配新架构下的交付模式。开发团队大多关注代码和架构，对于产品如何能在生产环境稳定运行、需要考虑哪些安全性和可持续性的因素并不是很了解。
问题分析和挑战
通过对这些问题和各个团队反馈的深入分析，发现其中最大的瓶颈在于交付团队与运维部门之间的各种依赖和沟通浪费，而这个瓶颈又是解决大多数问题的前提。
我们将瓶颈具象化后（如上图），可以看到两种团队之间其实是存在一堵墙的，一是因为传统的部署流程非常繁琐和低效。二是因为两种角色关注点和目标的不一致。
如果在这样的情况下，想实现微服务架构转型，实现更快速和安全的交付，只会更快的暴露出这堵墙引起的各种问题。开发阶段，系统的架构和依赖环境都是Developer说了算，对生产环境的关注度不高。部署、发布阶段，Operations会考虑如何构建一套稳定的基础设施，又如何去部署和运维开发的产物，但是往往对于产物的了解不充分，对于产物的周边生态和与它们关系的了解也不够。
那么引入DevOps文化，消除开发与运维之间的壁垒，逐步打造更高效的交付流程就成为我们破局的关键，那我们应该怎么做呢？
改革之初，我们发现并去尝试了Bimodel(双模IT)，我们看看它是否能解决我们的问题：
先简单介绍一下什么是双模IT:
它将IT系统分成了两种模式:
一种是新型的数字化、高市场适应性的IT，这部分业务聚焦企业新市场和业务的开拓，创新和发展，强调IT自身对于市场的高适应力。
另外一种模式下，我们则需要稳固发展，对于传统模式我们倾向于更加严谨和标准的流程去保护现有业务，稳定性比速度更加重要。
我们从采用这样一种模式的实践案例中发现：组织内部会出现连两种速度的交付流程，好的情况可能是采用敏捷开发流程的交付线，有着快速的交付能力，相反，对于继续采用传统开发流程和运维方式的团队，保持着稳定但低效的交付能力。
从业界很多公司的现状和发展趋势来看，双模IT确实是很多组织存在的现状或是必然经历的过程，但不是一个好的模式，从实际的交付过程来看，存在4点问题：
双模IT的划分方式更多是基于软件系统，而不是从业务活动出发进行的，所有软件系统的交付都应该是面向业务价值的。
双模IT会让我们误以为速度的提升会引起质量的下降，但是对于我们在ThoughtWorks的很多敏捷实践中学到的：随着交付的推进，质量内建是团队共同负责和持续改进的重点。交付速度的提升，往往都伴随着质量的保障，而不是忽视质量。
实际生产中，一个新的产品或者功能往往会依赖很多遗留系统提供的服务，如果它们仅仅只能达到稳定和低效的交付，对企业来说对市场整体的响应能力也会越来越低。
企业的创新不仅仅只是从零创造一个新的产品，还有很多机遇现有的资源。一个新的系统和功能往往不仅会既涉及到新服务、应用的创建，也会涉及到遗留系统的修改，调整和改造。
由此可见双模IT是在以一种试图掩盖问题的方式来逃避目前最重要的问题：开发和运维之间的壁垒。感觉像是一个病人先是放弃治疗，然后又努力的寻找延长寿命的方法，有些隐患终会爆发。
打造自服务持续交付
紧接着，我们开始采用了一种看似不可行的方式开启了DevOps转型，建立公有DevOps团队。有很多人可能会说这是一种反模式，怎么可能会建立一个团队专做DevOps相关的事情，那和以前的运维部门又有什么区别？DevOps提倡的Dev与Ops高频度合作的文化是不是就无法大面积传播了？
因此我们需要很明确的定义我们对这个团队的期望和它的职责是什么，它是怎样和交付团队合作，影响交付团队，最终能让DevOps的文化可以大面积传播。这个团队的目标是要像杠杆一样，翘起更大面积的DevOps变革。
所以我们认为公有DevOps团队应该与其它的端到端交付团队的人员构成是一样的。不同的只是目标和价值，主要体现在帮助更多的团队植入DevOps文化、优化持续交付流程。最终达到的目标是每个团队都可以自治，每个团队都可以进行端到端的开发、测试和部署，并可以自驱动的持续改进。与此同时，这个团队不仅仅只是为交付团队提供更多涉及基础设施、持续交付流水线、部署等活动所需要的自动化能力，还会支撑交付团队根据自身的上下文去定制和规划自己的持续交付流程和部署策略等。
（图片来自：http://t.cn/R9jnzHR）
现在，相比于DevOps团队的叫法，我们更愿意称呼这个团队为Platform团队，一个原因是我之前所说的避免被错误理解，另一个原因是随着各个交付团队逐步实现自服务持续交付，这个专有团队也有了更高的目标：持续打造和优化一个能够支持各交付团队快速交付的平台。
当时，我们首先为团队定义了新的工作方式：以自服务，自动化和协作作为核心文化，希望团队通过提供便捷的基础服务，让交付团队拥有自动化的交付流水线，并通过更多的沟通协作，尽可能让每个交付团队都能够独立自主的设计、创建和更改自己的基础设施。然后再根据各个交付团队的实施情况和结果来对流程和服务持续改进。
所以第一件事，我们首先设计了一个高效的持续交付流水线，让Platform团队和交付团队建立触点：
如下图所示，蓝色的基因链为交付团队的持续交付环，红色的基因链为平台团队的持续交付环。两种团队以某种低耦合的弱连接进行全程协作，Platform团队在整个端到端的交付过程中都要能尽量通过构建自动化能力来支撑交付团队能够快速、安全的进行持续集成、部署等活动。这样的合作方式也给我们提供了优化触点的可能性，也能够通过优化和改进，缩小这个持续交付周期，让交付更高效。
请原谅我在这篇文章进入高潮时卖个关子，由于考虑到大家的阅读体验，所以文章分成了上、下两个部分，上半部分主要讲DevOps转型的动机、策略和方法，下半部分会讲我们如何实际应用基础设施即代码来建立Platform团队和交付团队的触点，又怎样让遗留系统团队和微服务团队的交付速度成倍增加。敬请期待！
- 相关阅读 -
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。